Downloading web pages

ABSTRACT

A method of enhancing sessions or applications protocols which use successive transmission control protocol connections within a session on time division multiple access wireless packet data systems or wireline modem access protocols, wherein temporary block flows are chained. The present invention provides for a method and system for utilising sessions or applications protocols which use successive transmission control protocol connections within a session on time division multiple access wireless packet data systems or wireline modem access protocols. The method and system have the advantages of reducing the download time for web pages and reducing the number of random access contentions experienced.

[0001] This invention relates to the downloading of web sites on timedivision multiple access (TDMA) wireless packet data systems or wirelinemodem access protocols using sessions or applications protocols whichuse successive transmission control protocol (TCP) connections within asession. More specifically, this invention relates to methods ofreducing the time overhead involved in such downloads, and reducing thenumber of random access contentions in such systems.

[0002] When a client (web browser) initiates web access, a transmissioncontrol protocol/internet protocol (TCP/IP) connection is establishedbetween the client and the web server, as shown in FIG. 1. Theconnection is established utilising what is known as a three-wayhandshake. Firstly, the client sends a SYN (synchronise idle character)signal to the server, which in turn sends a SYN signal back to theclient. The client then sends an acknowledgement signal to the server,thereby acknowledging receipt of the server's SYN signal and connectionis complete.

[0003] Once a connection has been established between the client and theserver, the client sends a hyper text mark-up language (HTML) request tothe server. Such a request may be sent as a single TCP message or may besplit into two such messages. The connection is characterised by what istermed a slow start mechanism. The client sends a single HTML request,awaits a response from the server, typically including the requesteddata, and sends an acknowledgement to the server. After transmission ofthe acknowledgement, multiple data signals are received from the server,such receipt is facilitated by the client. Once all data is received,the server sends a finish signal. A finish acknowledgement signal issent from the client to the server, and then a finish signal.

[0004] The downloading of a web page involves several TCP/IP connectionestablishment and tear down sequences. This is because, if the web pageto be downloaded comprises more than one inline image, a separate TCPsession is required for the transfer of each image from the server tothe client. FIG. 1 illustrates this problem, whereby once the finishedsignal 102 has been transmitted by the client, the client parses(checks) the downloaded page to see if more data is required. For theexample of FIG. 1, an image requires downloading, so the above detailedconnection establishment and tear down sequence is run again. In thisinstance, there is only a single data element which is less than 1 radiolink control (RLC) packet to be sent, thus the server sends a singledata signal followed by a finish signal. In this instance, the slowstart mechanism is not invoked.

[0005] It is thus clear that, in order to download a web page containinga plurality of images, a number of TCP connections must be made betweena client and a server. This is undesirable in terms of the time overheadfor the overall download of a web page.

[0006] There exists a problem in accessing the worldwide web (WWW) usingsessions or applications protocols which use successive TCP connectionswithin a session on TDMA wireless packet data systems or wireline modemaccess protocols. This is illustrated hereinafter with reference to theuse of hyper text transfer protocol (HTTP) on a global packet radiosystem (GPRS). When a browser sends an HTTP request, the request istransmitted as a SYN signal. However, every time a SYN signal is sent onGPRS there is a random access attempt made by the mobile station (MS)being utilised to connect to the network and thereby to a remote WWWserver to facilitate the download of a required web page.

[0007] Upon the occurrence of a random access attempt, the MS sends amessage to the network, via a base transceiver station (BS), that it hasdata to send. When the MS receives a signal from the network that it maysend data, the MS is allocated a number of packets of future time inwhich to send that data. However, if there are two requests made to thenetwork at the same time, collision of access attempts may occur. Inthis event, a SYN signal will not be transmitted by the network and theMS must make a further random access attempt later in time. This isknown as random access contention resolution.

[0008] As will be explained below, the problem that exists is thenecessity to establish a radio link control (RLC) link for every TCP/IPsession. Radio link control is a protocol which controls the transfer ofblocks of information between the MS and network. It performs sequenceddelivery and error correction. The need to establish separate radiolinks increases substantially the delays experienced by the user indownloading a web page and the images contained therein. Delays arefurther accentuated given that the current form of RLC protocol requiresthat a countdown procedure is used to close down a link. Such aprocedure consists of counting down the remaining number of blocks to besent from a pre-set number to zero. The shut down of the link occursupon zero.

[0009] The delays that occur during the download of a web page may bestbe appreciated by referring to FIG. 2, which shows a ladder diagramillustrating the message exchanges involved in the sending of a SYNmessage from client to server and from server to client. The followinggeneral assumptions have been made in the construction of the ladderdiagram. It should be stressed that these assumptions are purelyexemplary.

[0010] 1. The major time delays are attributed to temporary block flow(TBF) establishment and wide area network (WAN) and data transfer time,such as satellite delay when making a transatlantic connection, forexample.

[0011] 2. The time overhead for the creation of an uplink TBF is largerthan the time overhead for the creation of an uplink TBF whilst thedownlink TBF is active.

[0012] 3. The establishment of a downlink TBF has a time overhead lessthan that for the establishment of an uplink TBF.

[0013] 4. Data transfers have an associated block error rate (BLER) of10%.

[0014] 5. The RLC roundtrip delay for data transfers is 10 RLC blocks.

[0015] 6. Data is transferred at the lowest code rate (highestthroughput).

[0016] The terminology used within these assumptions will become clearerin the light of the following description relating to FIG. 2.

[0017] As may be seen in FIG. 2, the connection between web browser andremote server on a GPRS involves various layers of control whichinteract with one another to enable communication links to be created. Abrowser communicates via a transmission control protocol (TCP) layer,which communicates with a logical link control (LLC) layer, whichcommunicates with the mobile station radio link control (RLC-MS) layer.From here, messages are broadcast from MS to BS across a radio linkformed therebetween. Messages received at the base station radio linkcontrol (RLC-BS) level are communicated to a logical linkcontrol/transmission control protocol (LLC/TCP) layer and thereon to theTCP layer of the remote server. Of course, this operates in reversealso.

[0018] Referring again to FIG. 2, the browser sends a HTTP request 2which is sent as a SYN signal 4 by the TCP layer, this signal is sent onas a set synchronise balance mode (SABM) signal 6, by the LLC layer tothe RLC-MS layer. At this stage an uplink TBF 10, a connection betweenMS and BS for the transfer of information in terms of RLC blocks, isestablished.

[0019] After establishment of the uplink, a TCP signal is passed on fromthe RLC-BS layer to the LLC/TCP layer as a connection indication(Conn-ind) signal 12. An acknowledgement signal 14 is sent back fromthis layer to the LLC layer which in turn sends an information frame 16,comprising TCP information and a SYN signal, back to the LLC/TCP layer.The next stage involves the sending of a SYN signal 18 from the LLC/TCPlayer to the TCP remote server. This then sends a SYN signal 20 back,which is transmitted onwards to the RLC-BS as an SABM signal 22.

[0020] Now a downlink TBF-connection for transmittal of RLC blocks fromBS to MS is established. This step is generally indicated as 24. Afterdownlink establishment, a connection indication (Conn-ind) signal 26 issent onwards to the LLC layer. This is acknowledged by acknowledgementsignal 28 which passes across the air interface between MS and BS to theLLC/TCP layer. From there an information frame is sent across the radiolink and onwards to the browser TCP layer.

[0021] Here it is assumed that the downlink TBF is closed after pollingusing the related reserved block period (RRBP). A BS may send a messagewith the RRBP set so that the MS must respond with an acknowledgementsignal at the RLC level within a certain number of RLC blocks. If theRRBP does not require that the downlink remain open for such anacknowledgement, the downlink will be closed.

[0022] It is clear to see that these two signals, the first two depictedin FIG. 1, have taken a specific time (τ) to be passed. Such aconnection must be made a number of times in any one web page downloadoperation. There is thus a problem in that the requirements fordownloading web pages using HTTP on a GPRS can be very high. The statedproblem becomes more significant when exemplified with regard to timeperiods. For the download of a single web page containing no images,three connection and tear down sequences must be carried out. One toestablish that data is required, one to notify the server of what datais required and to receive the data, and a final one to acknowledge.Obviously, this will increase by the duration of a further connectionand teardown sequence for every image to be downloaded. The problemrequiring a solution is, therefore, how to reduce the time requirementsfor downloading a web page using sessions or applications protocolswhich use successive TCP connections within a session on TDMA wirelesspacket data systems or wireline modem access protocols, thus increasingefficiency and user satisfaction.

[0023] The present invention aims to address some or all of the abovedisadvantages.

[0024] The present invention provides as claimed in the appendantclaims, a method for enhancing sessions or applications protocols whichuse successive transmission control protocol (TCP) connections within asession on time division multiple access (TDMA) wireless packet datasystems or wireline modem access protocols, wherein temporary blockflows (TBFs) are chained. The present invention also provides methodsfor the reduction of web page download time and for the reduction ofrandom access contentions in time division multiple access (TDMA)wireless packet data systems or wireline modem access protocols, andtime division multiple access (TDMA) wireless packet data systems orwireline modem access protocols all utilising TBF chaining.

[0025] According to a preferred embodiment of the present invention,there is provided a method wherein an existing downlink TBF is utilisedto request a rendezvous point from a network.

[0026] In another aspect of the present invention, there is provided amethod wherein an existing uplink is utilised to request a rendezvouspoint from a network, prior to its closure.

[0027] In another aspect of the present invention, there is provided amethod wherein a network maintains a downlink TBF constantly active.

[0028] The different aspects of the present invention may be utilisedseparately, or in any combination. They may also utilise the steps ofdetermining the number of TCP sessions required to download an entireweb page, and thereby transmitting information relating to the remainingnumber of required TBFs to a network.

[0029] Additional specific advantages of the present invention areapparent from the following description of Figures in which:

[0030]FIG. 1 shows the messages exchanged between a client and a serverduring the download of a web page;

[0031]FIG. 2 shows the messages exchanged during the first two signalsin a three-way handshake using HTTP on a GPRS;

[0032]FIG. 3 shows a ladder diagram depicting the scenario in which aconnection between client and host remains open;

[0033]FIG. 4 shows a ladder diagram depicting a rendezvous request;

[0034]FIG. 5 shows a flow diagram illustrating a time locationcalculation for the rendezvous of FIG. 4;

[0035]FIG. 6 shows a flow diagram illustrating a method of TBF chainingusing a closing uplink;

[0036]FIG. 7 shows a flow diagram illustrating a time locationcalculation for the rendezvous point of FIG. 6;

[0037]FIG. 8 shows a flow diagram illustrating a method of TBF chainingwherein a downlink remains always active; and

[0038]FIG. 9 shows a flow diagram illustrating a method of informing anetwork of status information.

[0039] The present invention is now described with reference to theaccompanying drawings as detailed above.

[0040] The present invention operates upon the basis that, if a TBFremains active in some way, even when no data is being transferred,there will not be required a stand alone TBF establishment for eachcommunication between the MS and the network. This is termed TBFchaining.

[0041] As may be seen from FIG. 3, once an uplink TBF has beenestablished, 302, 304, 306 between the RLC-MS and RLC-BS of the clientand server, an HTML request may be sent 308 which will result in dataand finish signal 310, 312 being passed back from the server to theclient. At this stage, the uplink TBF remains active. It is thuspossible for transmission 318 to occur thereafter, after a RLC/MACchannel resource assignment procedure. There is no need to create anuplink TBF connection with its associated time overheads. This result isachieved in a number of different ways which are described below withreference to FIGS. 4 to 9.

[0042]FIG. 4 shows the messages passed between an MS and a BS when adownlink TBF is used to request a rendezvous point from an uplink TBF.FIG. 4 is representative of an extract of a ladder diagram showingmessages passed between an MS and BS. The first signal 402, an LLC levelsignal, passed from BS to MS is representative of the last communicationsent through an established downlink from a BS to an MS. After receiptof this signal, and prior to downlink closure, the MS sends a requestfor a rendezvous, an RLC level signal. In other words, the MS sends amessage back through the downlink, before its closure, indicating thatit may want to transmit something based upon TCP/HTTP conditions. Ineffect, when RRBP is polled (c.f. FIG. 2), the MS sends a message to theBS requesting resource. The MS provides details of the minimum number ofRLC blocks before the expiry of which it will not be ready to transmitdata. In response to this, the BS allocates a contention free resourcefor this purpose. This resource consists of a block of time allocatedsolely for the use of the MS. The block is located a certain number ofRLC blocks after request and is named a rendezvous point.

[0043] The block allocated for the use of the MS enables the MS toinform the BS of whether it has any more data to transmit. Thus, the MSmay use this block to request necessary resource for data to betransferred from the server to a client, or to indicate that it hasnothing further to transmit, or to request a further rendezvous point.

[0044] This procedure reduces the time to create an uplink TBF from theuplink TBF establishment time (standalone) to the time taken to createan uplink TBF through a downlink TBF. However, it should be noted thatthe bandwidth of the allocated RLC block is wasted if the MS has nothingfurther to transmit when the rendezvous point is reached, and thus doesnot use the allocated RLC block. Additionally, the number of randomaccess contentions occurring is reduced because resource for an uplinkrequest has already been allocated.

[0045] The time for which the rendezvous point is requested iscalculated using time and data which the MS maintains. The MS maintainsa timing record per each web or internet protocol (IP) address (or for alimited number of addresses in a circular storage area). It alsomaintains a timing record at the radio link control/media access control(RLC/MAC) level (previously termed solely RLC) for the network currentlyin service. For each IP address, the RLC/MAC network interface usedduring the measurement is stored. In order to maintain such records, theMS measures the following timings when they are required and inaccordance with what is allowed by the various protocols involved. TheMS may use any method for maintaining measurements. Such methods mayinclude averaging over a number of previous measurements or simply usingthe latest measurements:

[0046] 1. The stand alone uplink establishment time. This is the RLC/MACuplink TBF establishment time, and is the time between the first randomaccess attempt and the receipt of a “packet assignment” message (amessage indicating the assignment of resources for transmission of dataon an uplink).

[0047] 2. The stand alone downlink establishment time. This is the timebetween the receipt of a “packet downlink assignment” message and thereceipt of a first valid RLC block.

[0048] 3. The uplink TBF establishment time whilst a downlink TBF isstill active.

[0049] 4. The downlink TBF establishment time whilst an uplink TBFremains active; and

[0050] 5. The TCP roundtrip time. This is the time for a TCP message tobe transmitted from the TCP layer of a client or MS, to the TCP layer ofa server (remote or otherwise) and back to the MS.

[0051] In addition to the above parameters, the MS also takes intoconsideration the uplink and downlink data rates and their respectiveblock error rates when determining the desired time for rendezvous pointlocations.

[0052]FIG. 5 illustrates how an MS of the embodiment of FIG. 4 requestsa rendezvous point. In function box 502, the MS determines whether moredata needs sending and also the size of the remaining data. This isdetermined from the condition of the HTTP and/or the TCP. This can occurat any time in which a downlink TBF is active.

[0053] In function box 504, the MS waits until it knows the size of thedownlink TCP message which is currently being sent. The MS thencalculates the time at which it should have received the completedownlink message, taking into consideration the downlink data rate andblock error rate. The calculation also takes into account the messageswhich need to be transacted at different levels of control within theclient/server interface.

[0054] Function box 506 details the resource request transmission step.Here the MS transmits a request for 1 RLC block of uplink at arendezvous point equal to the time determined in function box 504. TheTCP roundtrip time is used as a benchmark to prevent the rendezvouspoint from being requested for a time that is too early. If therequested point falls at a time sooner than a TCP roundtrip time, thenetwork would be ready to establish resources before there is anythingto send. Similarly, if the time until the rendezvous point is muchlonger than either of the RLC uplink TBF establishment times, or if theuplink TBF is active, the request is not sent. The network reserves theright to allow, delay, or reject any request for resource.

[0055] Function box 508 depicts a decision which is made by the MS. If,after the number of blocks between the rendezvous request and theallocated block, the MS has more data to transmit, then that data istransmitted to the BS, as detailed in function box 510. However, if theMS has no further data to transmit it is determined (function box 512)whether rendezvous requests are allowed. This is done by the MSlistening to the network's system information messages which arebroadcast continuously. The network sets a bit within these messages toindicate whether rendezvous requests are accepted. The MS will listen tothis information before making a call.

[0056] If rendezvous requests are accepted, it is established (functionbox 514) whether rendezvous request retries are allowed. Thisinformation is available in the same way as detailed for whetherrendezvous requests are accepted.

[0057] If both requests and retries are accepted, function box 502 isreturned to. However, if either, or both, of these requests are notaccepted by the network, communication between the MS and network comesto an end (function box 516).

[0058] A second method of chaining TBFs is depicted in FIG. 6. In thismethod, an MS utilises the countdown procedure of the RLC level inrequesting a rendezvous point for the next uplink TBF.

[0059] Function box 602 indicates the RLC countdown. The RLC protocolrequires that as the MS starts to have fewer blocks of data to send, itmust inform the network. As such, a countdown, from a pre-set number ofblocks remaining to be transmitted, to zero, is carried out. This allowsthe network to be informed of how much data remains, and whentransmission will be completed. When the count reaches zero, the end ofthe data is also reached. In this embodiment, the MS parallels thecountdown and, when the countdown is equal to zero (function box 604),the MS sends a request for a single resource to be allocated. The blockis requested to be allocated at a future time, for the purpose ofrequesting data transfer. As such, the MS indicates a rendezvous pointfor the allocation of a block. This is carried out at the same time asthe existing uplink TBF is closed. Whilst the countdown is not equal tozero, the MS takes no action in this regard (function box 608).

[0060] This method is advantageous in that as a block has already beenallocated for requesting resource for the next uplink TBF, thecontention resolution procedure inherent in random access attempts, asexplained earlier, is avoided. This reduces the time overhead forestablishing further uplink TBFs (i.e. uplinks established after thefirst or primary uplink) from the standalone uplink establishmentduration to that of the uplink establishment through an open downlink.

[0061] The rendezvous request procedure utilised in the embodiment ofFIG. 6 uses the same parameters as that of FIG. 5. However, the processof requesting a rendezvous point differs and is described with referenceto FIG. 7.

[0062] Function box 702 depicts the first step in the process ofrequesting a rendezvous point. This step requires that knowledge of thecurrent TCP roundtrip time is available for use. The MS calculates thetime elapsed since the start of the current TCP message at the point intime where the decision to request a rendezvous point is made, which isascribed the symbol T_(E). The next step, detailed in function box 704,takes place when the RLC countdown has reached zero. Here, the MSrequests a rendezvous point at a future time given as the differencebetween the TCP roundtrip time (T_(TCPR)) and time value calculated instep 702. Again, the network reserves the right to either admit, delayor reject the received request. Function box 706 details the decisiontaken by the MS as to whether or not it has further data to transmit, inthe form of an acknowledgement signal or request for resource forexample, when the rendezvous point is reached. If the MS has furtherdata, that data is transmitted as shown in function box 708. Otherwise,it is determined (function box 710) whether rendezvous requests areallowed. This is done by the MS listening to the network's systeminformation messages which are broadcast continuously. The network setsa bit within these messages to indicate whether rendezvous requests areaccepted. The MS will listen to this information before making a call.

[0063] If rendezvous requests are accepted, it is established (functionbox 712) whether rendezvous request retries are allowed. Thisinformation is available in the same way as detailed for whetherrendezvous requests are accepted.

[0064] If both requests and retries are accepted, function box 502 isreturned to. However, if either, or both, of these requests are notaccepted by the network, communication between the MS and network comesto an end (function box 714). It should be noted that one or morecorrection factors may be utilised within this procedure.

[0065] A third method of chaining TBFs, wherein a network retains anopen downlink TBF at all times, is described with reference to FIG. 8.As may be seen from FIG. 8, this method relies upon the downlink TBF(c.f. 24, FIG. 2) being kept open by a BS after an HTTP or TCP/IPsession transaction has been carried out.

[0066] Function box 802 details the step of the BS receiving an estimatefrom the MS of the minimum number of future RLC blocks before which itwill not be able to transmit further data. This information is sent asoften as the MS can send it along with information detailing the currentroundtrip TCP delay being experienced.

[0067] The next step 804 consists of the BS polling the MS periodicallyto see whether the MS has made any uplink resource requests. If arequest has been made, an uplink TBF is established 806, 808 at thesmaller of the two establishment overheads detailed earlier because thedownlink TBF remains open. If no request has been made, the BS continuesto poll the MS periodically.

[0068] This method provides a network control procedure. If a BS is, ata particular time, dealing with a high proportion of network traffic, itmay choose not to poll an MS for resource requests. The BS may delay thetime when it will next poll an MS. Thus, this method provides amechanism controlled by the network for dealing with collisions. Randomaccess contentions may be avoided, because when they are likely tooccur, the BS merely delays the polling of the MS. A contention freeresource is therefore provided. This method provides the same timesaving as the previous methods.

[0069] A final method, complementary to the chaining of TBFs, isdetailed in FIG. 9. This method may be used with any of the above threemethods of chaining. This method begins in an MS. The MS, step 902,determines the number of TCP connections/tear down sequences which willbe required in order to download a web page. As already explained, anindividual sequence is required for each inline image to be downloaded.This step utilises HTTP page parsing.

[0070] In function box 904, an indication of the number of TBFs stillrequiring establishment in order to complete the download is passed tothe network. This indication is made by means of a counter. In addition,the MS can indicate the number of octets (bytes) of data that it mayhave to transfer on the uplink in future TBFs. This occurs particularlyin uploads wherein the nature of events is similar.

[0071] The above methods may all be employed together to provide TBFchaining in download of web pages using HTTP on a GPRS. However, themost likely and preferred combinations are the embodiments of FIGS. 4, 8and 9, and the embodiments of FIGS. 6, 8 and 9.

[0072] The above methods, however combined, serve to reduce the timeoverhead of TBF establishment using HTTP in a GPRS. The gains achievedby the use of TBF chaining, in an exemplary download scenario, are nowdescribed. In the download of a page containing four images, five TCPconnections would be required. One for the page, and one for each image.For each of these connections there will be up to four uplink TBFestablishments and up to three downlink TBF establishments. It is thusobvious that reducing the time taken to establish each such link willsignificantly reduce the overall time overhead for a download. Also, asHTTP improves, bottlenecks will only remain in the form of the TCProundtrip time for connection establishment and slow start. Further,chaining TBFs provides noticeable improvements in the most desirousarea.

[0073] There is also a band width gain associated with TBF chaining. Asthe number of messages exchanged between control levels in both clientand server (i.e. in order to establish a connection) is reduced, fewerRLC blocks are required in order to connect. Thus, more RLC blocks areavailable to the user for data transfer, etc. Further, the reduction inthe number of random access contentions results in a significantreduction in collisions, which has an associated saving in time, aspreviously described.

[0074] The above detailed description provides for methods of improvingthe use of HTTP on GPRS's and GPRS systems utilising such methods, forpredicting rendezvous points, and for avoiding collisions and contentionresolution in a GPRS utilising HTTP. These methods have been describedas relating to GPRS, but apply equally to any time division multipleaccess (TDMA) wireless packet data system and any wireline modem accessprotocol. Further, whilst the methods and systems of this invention havebeen described with reference to hyper text transfer protocol, theyapply equally to any sessions or applications protocols utilisingsuccessive transmission control protocol (TCP) connections within asession.

[0075] It will be of course be understood that the present invention hasbeen described by way of example only, and that modifications of detailmay be made without departing from the scope of the invention.

1. A method of enhancing sessions or applications protocols which usesuccessive transmission control protocol (TCP) connections within asession on time division multiple access (TDMA) wireless packet datasystems and wireline modem access protocols, wherein temporary blockflows (TBFs) are chained.
 2. A method of reducing the download time of aweb page using sessions or applications protocols which use successiveTCP connections within a session on TDMA wireless packet data systemsand wireline modem access protocols, wherein temporary block flows(TBFs) are chained.
 3. A method of reducing the number of random accesscontentions in TDMA wireless packet data systems and wireline modemaccess protocols using sessions or applications protocols which usesuccessive TCP connections within a session, wherein temporary blockflows (TBFs) are chained.
 4. A method according to any preceding claim,wherein the sessions or applications protocols include hyper texttransfer protocol (HTTP) and the TDMA wireless packet data system andwireline modem access protocols include global packet radio systems(GPRSs) and enhanced GPRSs (EGPRSs).
 5. A method according to anypreceding claim, comprising: utilising an existing downlink TBF torequest a rendezvous point from a network.
 6. A method according toclaim 5, wherein said rendezvous point is requested to be located at apoint in time when an uplink TBF may be required.
 7. A method accordingto claim 6, wherein the rendezvous point location is calculated, saidcalculation comprising the steps of: determining whether further dataneeds sending to the network, and determining the size of the data; andestimating the time when the current downlink signal should be complete.8. A method according to any of claims 5 to 7, wherein the rendezvouspoint comprises a single radio link control (RLC) block of uplink.
 9. Amethod according to claim 8, further comprising the step of, if therendezvous point is allowed by the network, when the rendezvous point isreached, and if data to be transmitted is present, utilising the blockof uplink to request an uplink TBF.
 10. A method according to any ofclaims 1 to 4, comprising: utilising an existing uplink TBF to request arendezvous point from a network.
 11. A method according to claim 10,wherein the request is made as data transmission ends.
 12. A methodaccording to either of claims 10 or 11, wherein the request is made asan RLC counter reaches zero.
 13. A method according to any of claims 10to 12, wherein the rendezvous point is requested to be located at apoint in time when an uplink TBF may be required.
 14. A method accordingto any of claims 10 to 13, wherein the rendezvous point is calculatedaccording to the following steps: calculating the time lapsed sincetransmission of a current TCP message; and estimating the rendezvouspoint as the difference between the elapsed time and a TCP roundtriptime taking account of any required correction factors.
 15. A methodaccording to any of claims 10 to 14, wherein the rendezvous pointcomprises a single RLC block of uplink.
 16. A method according to claim15, further comprising the step of, if the rendezvous point is allowedby the network, when the rendezvous point is reached, and if data to betransmitted is present, utilising the block of uplink to request anuplink TBF.
 17. A method according to claim 9 or claim 16, furthercomprising the steps of: if the rendezvous point is rejected by thenetwork, determining whether rendezvous requests are accepted by thenetwork; if rendezvous requests are accepted by the network, determiningwhether re-requests are accepted by the network; and if re-requests areallowed, repeating the rendezvous request procedure.
 18. A methodaccording to any of claims 1 to 4, comprising the step of a networkmaintaining a downlink TBF as active.
 19. A method according to claim18, further comprising the steps of: receiving an estimate from a mobilestation (MS) of the minimum number of RLC blocks before which it willhave nothing to transmit; and polling the MS for an uplink resourcerequest.
 20. A method according to claim 19, comprising the step of, ifa resource request is identified, opening an uplink TBF between the MSand the BS.
 21. A method according to any of claims 4 to 17, wherein anetwork to which a request for a rendezvous point has been made mayaccept, reject or delay the request.
 22. A method according to any ofclaims 4 to 21, further comprising the steps of: determining the numberof TCP sessions required to download a web page; and transmitting anindication of the remaining required TBFs to a network.
 23. A methodaccording to claim 22, further comprising the steps of transmitting tothe network an estimate of the size of the data to be uploaded in futureTBFs.
 24. A TDMA wireless packet data system or wireline modem accessprotocol which uses a method according to any preceding claim.
 25. ATDMA wireless packet data system or wireline modem access protocolcomprising means for chaining TBFs.
 26. A method for enhancing sessionsor applications protocols which use successive TCP connections within asession on TDMA wireless packet data systems or wireline modem accessprotocols, substantially as hereinbefore described with reference toFIGS. 3 to 9 of the accompanying drawings.
 27. A method for reducing thedownload time of a web page substantially as hereinbefore described withreference to FIGS. 3 to 9 of the accompanying drawings.
 28. A method forreducing the number of random access contentions substantially ashereinbefore described with reference to FIGS. 3 to 9 of theaccompanying drawings.
 29. A TDMA wireless packet data system orwireline modem access protocol substantially as hereinbefore describedwith reference to FIGS. 3 to 9 of the accompanying drawings.